ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group95b.txt/000051_icon-group-sender _Sun Jun 18 16:09:07 1995.msg

Internet Message Format | 1995-09-18 | 5KB

Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:02:35 MST
To: [e-mail]
Date: 18 Jun 1995 16:09:07 +0100
From: [e-mail] (Ian Phillipps)
Message-Id: <3s1fij$[e-mail]>
Organization: PIPEX, 216 Science Park, Cambridge, England
Sender: [e-mail]
References: <[e-mail]>, <[e-mail]>
Subject: Re: Perl v. Icon
Errors-To: [e-mail]

In article <[e-mail]>, John Shipman <[e-mail]> wrote:
>I've been a heavy Icon user for a year or so now, and I think
>it's a good choice for text processing applications, especially
>when you need a good selection of data structures.

OK, I'm a heavy perl programmer (not that heavy for my height, though).
A couple of years ago I looked fairly closely at Icon, and elected to
remain with Perl.

With Perl 4 and earlier, the weak point was, as John implies, data
structures, although the split and join operators provided quite
convenient workarounds.

Judging what I remember of Icon (version 8, I think) and perl 5, here's
my assessment of relative strengths: (P=Perl stronger, I=Icon stronger)

P    Online documentation (Full icon docs are only available as a
    conventional book)

PPP    Regular expressions. This is the biggie as far as I'm concerned.
    The sort of job where you're trying to parse incoming data which
    has a slightly unknown syntax.  By comparison, the Icon method
    of lots of operators to scan across a string is seriously
    clunky.  (BTW the date I finally gave up on Icon is when I read
    in the Icon newsletter that Ralph Griswold was never going to
    put REs into Icon)

-    List structures

I    List processing. The list-traversal primitives of Icon are still
    better that those of Perl. Things like lazy evaluation fall
    directly out of Icon syntax.

?    Syntax. I don't agree that Perl syntax is ugly, at least no more
    than any other computer language. It's unconventional,
    certainly, to put "$" before all scalars. But after a very short
    while you know that "$" means it's a scalar, and is helpful.
    Icon's use of syntax "looks cleaner" but is, if anything, rather
    more unconventional. This is another area where Perl 5 has
    made a difference.

P    Support. I don't currently subscribe to comp.lang.icon, but
    you'd be hard put to it to find a friendlier place to ask daft
    questions than comp.lang.perl.misc (new name..). Oh, and get
    answers :-). C.l.p postings outnumber c.l.i. postings by around
    30 to 1, not that that proves anything.

I?    Icon has a two-phase interpretation process, which is cumbersome
    for quick one-shot programs, but a payoff for bigger ones.
    (I think you can work round this by using "eval", but I don't
    really remember).

I    Co-expressions. This is a very powerful paradigm - a
    generalisation of co-routines - built into the Icon
    language (although at the time I could only really play on DOS
    and was greeted with "co-expressions not implemented").

P    The full specification of perl and its libraries is available
    on-line. "You can't search dead trees".

>The input is a list of skills (C++, hardware repair, etc.),
>structured as a three-level hierarchy (major category, minor
>category, and skill name), with each skill followed by a list
>of people who have that skill, and a rating of B for beginner,
>I for intermediate, and E for expert.

Hmm.. I'd give this project around 2-3 days in perl, at the most.
[Resists temptation to include perl solution in posting :-)]

>applications will need.  Although Icon is not technically an
>object-oriented language, I can still get the kind of
>encapsulation and abstraction that I need.

If we were comparing Icon with perl 4, I'd vote for Icon on this. Perl 5
levels this playing field.

>to person.  The Icon concept of generators gives me a foolproof
>way to allow the caller to visit each child of a parent node, for
>example, without having to worry about how the tree is
>structured.

>As a further disclaimer, I'm rather manic about good style.  I
>want my programs to be legible, and I find that Icon gives me
>a very natural expression of the problem.  I also find that
>modifying programs is straightforward.

A danger with any powerful language is that it can be too concise for
its own good. While neither Perl nor Icon can compete with APL in this
league, it's possible to write exceedingly cryptic programs in each.
Or in any programming language, for that matter (see
ftp://gatekeeper.dec.com/.8/misc/ioccc/1988/phillipps.c, for instance)
It's a programmer's job to explain what's not obvious - the problem is
to remember what that is!

Generators are nice - if you know what's going on. If not, they can be
very puzzling, since the paradigm is unique to Icon.

>Since I discovered Icon, I have written negligible amounts of C,
>and nothing in Awk.  Most of my work involves transformation of
Sounds like my experience with Perl :-)

>text input files into text output files (although I have done a
>little work with portable binary encodings in files), and I'd say
>I'm three times as productive as with C and twice Awk.

Hmm.. I'd be surprised if awk were only twice as good as C in its
domain. For text-bashing, I'd put the C:awk:perl ratio at 1:3-10:8
The awk figure depends heavily on whether you have to work-around the
limits in it.

Ian